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And-Inverter Graphs (AIGs) are a popular way to represent Boolean functions (like circuits). AIG 
simplification algorithms can dramatically reduce an AIG, and play an important role in modern 
hardware verification tools like equivalence checkers. In practice, these tricky algorithms are im- 
plemented with optimized C or C++ routines with no guarantee of correctness. Meanwhile, many 
interactive theorem provers can now employ SAT or SMT solvers to automatically solve finite goals, 
but no theorem prover makes use of these advanced, AIG-based approaches. 

We have developed two ways to represent AIGs within the ACL2 theorem prover. One repre- 
sentation, Hons-AIGs, is especially convenient to use and reason about. The other, Aignet, is the 
opposite; it is styled after modern AIG packages and allows for efficient algorithms. We have imple- 
mented functions for converting between these representations, random vector simulation, conversion 
to CNF, etc., and developed reasoning strategies for verifying these algorithms. 

Aside from these contributions towards verifying AIG algorithms, this work has an immediate, 
practical benefit for ACL2 users who are using GL to bit-blast finite ACL2 theorems: they can now 
optionally trust an off-the-shelf SAT solver to carry out the proof, instead of using the built-in BDD 
package. Looking to the future, it is a first step toward implementing verified AIG simplification 
algorithms that might further improve GL performance. 

1 Introduction 

Fully automatic tools like SAT and SMT solvers are now commonly used by interactive theorem provers 
to carry out certain proofs. For instance, in previous work ||28l we developed a way to solve finite 
ACL2 problems using a BDD package or a SAT solver. Similarly, Fox ifTTt implemented a translation 
from bit- vector problems in HOL4 into SAT problems which — thanks to integration work by Weber and 
Amjad [31] — can be solved by zChaff or MiniSat. Going further, Bohme, et al. [4 J present a method to 
solve bit- vector problems from Isabelle/HOL and HOL4 with the Z3 SMT solver. 

State of the art SAT and SMT solvers are heavily optimized C or C++ programs that are not intrinsi- 
cally trustworthy. For instance, Brummayer and Biere [ 10] report bugs in many SMT solvers that lead to 
crashes or — much worse — wrong answers! For SAT solvers we have some options for dealing with this: 

• We could simply trust the solver. This is pragmatic and allows us to use the fastest tools with 
minimal overhead, at the risk of getting a wrong answer. 

• We could check the solver's work. In the HOL family of theorem provers this checking is done in 
the usual LCF [18] style, which is quite satisfying but is also expensive. Faster checking is possible 
for provers that support reflection, e.g., Darbari, et al. [12J have implemented and reflectively 
verified a checker for SAT proofs in Coq. Some important SAT techniques cannot be checked with 
these methods, but Wetzler et al. [32] describe promising work to address this. 

• We could verify the solver itself. Marie l23l has formally verified many algorithms used in SAT 
solvers. Oe, et al. ll27l have developed and verified a solver in Guru, whose implementation 
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involves efficient, low-level structures like pointers, mutable arrays, and machine arithmetic. These 
efforts are inspiring, although performance is still not competitive with modern solvers. 

For SMT solvers there are similar approaches. For instance, the HOL connection to Z3's bit- vector 
reasoning checks the solver's work in the LCF style, and Armand et al. [1] have developed a reflectively 
verified Coq checker for certain SMT theories. 

This is a good start, but many hardware verification techniques go well beyond SAT. For instance, 
in Brayton and Mishchenko's [HI ABC system, circuits and specifications are typically represented as 
And-Inverter Graphs (AIGs). Algorithms like AIG rewriting [25] can significantly reduce the size of 
these graphs by analyzing their structure. Algorithms like fraiging ll26ll can simplify AIGs by using a 
combination of random simulation and SAT to find nodes that are equivalent and can be merged. These, 
and many other AIG algorithms, can greatly improve equivalence checking. 

Much like SMT solvers, these algorithms are implemented as optimized, tricky C++ routines that 
might easily have errors. We are not aware of any work to formally verify these tools. Although ways 
have been proposed [ 1 1 ] to emit proofs from some of these algorithms, existing tools do not generate such 
proofs. This leaves us with the choice of either (1) pragmatically using these tools, while accepting that 
they may not be correct, or (2) conservatively rejecting these tools as too risky, forgoing their benefits. 

This paper presents some results toward verifying AIG algorithms and incorporating these algorithms 
into ACL2. We have actually developed two complementary AIG representations: 

• A Hons-based representation that is especially simple and easy to reason about. The "graph" 
part of the And-Inverter Graph is kept outside of the logic by using the hash-consing features of 
ACL2(h), which avoids the sort of invariant-preservation theorems that you normally need when 
dealing with imperative structures. During proofs, we abstract away the details of the Hons-AIG 
representation and instead focus on semantic equivalence, a relation that is amenable to Greve- 
like [19] quantifier automation. We have implemented and verified algorithms on Hons-AIGs such 
as random vector simulation and conversion to BDDs. (Section [2]) 

• A stobj [6] based representation that is styled after ABC's and aimed squarely at efficiency. Here, 
the graph is an explicit stobj array. This is much harder to reason about: the graph is destruc- 
tively updated as nodes are added, so we need invariant- and semantics-preservation theorems. 
To deal with this, we develop an interesting extension relationship between AIG networks, and a 
bind-free-based strategy for using this relation. We have implemented and verified algorithms 
like random vector simulation, and also an efficient, somewhat "smart" conversion to Conjunctive 
Normal Form (CNF), which allows us to export AIGs to SAT. (Section [3]) 

Besides these contributions to reasoning about AIG algorithms, we have integrated our stobj based rep- 
resentation and its CNF conversion algorithm into the GL [28] framework for bit-blasting finite ACL2 
theorems. This allows GL to solve more theorems automatically, and opens up interesting possibilities 
for further scaling. (Section|4]). 

2 A Hons-Based AIGs Representation 

ACL2(h) is an extension of ACL2 that was originally developed by Boyer and Hunt Q . It extends ACL2 
with hash-consing and memoization features that make it quite easy to develop a Hons-based AIG library 
that is flexible, quite easy to prove theorems about, and reasonably efficient. 
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2.1 Representation and Semantics 

(Note: our Hons-AIG representation and semantics are briefly described in previous work by Swords 
and Hunt (29), we repeat some details here to make this paper more self-contained.) 

In the Hons-AIG library, an AIG is an object that represents a single Boolean function as a tree of 
AND and NOT nodes with constants and input variables as the leaves. We use t and nil to represent the 
constants true and false, and treat any other atom as a variable. We encode NOT nodes as conses of the 
form (a . nil), and AND nodes with any other cons, (a . ft). This special-casing of nil may seem 
awkward, but it lets us represent either kind of node with just one cons and, at any rate, it wouldn't be 
useful to AND together nil with another AIG anyway. 

The semantics of a Hons-AIG are given by an evaluation function, AigEval, that uses an environ- 
ment to give values to the variables: 



AigEval (x,env) 



nil 

t 

AlGENVLOOKUP^, env) 

-■AlGEVAL(a,ew) 



whenx = nil, 
whenx = t, 
when x is an atom, 
when x = {a . nil), or 



AlGEvAh(a,env) AAlGEvAh(b,env) wherex=(a . b) . 



Is it fair to call these AIGs? Implicit in the very name "And-Inverter Graph" is the idea of using a 
directed, acyclic graph (DAG) to represent a collection of Boolean functions. Where's the DAG here? 
We construct Hons-AIGs using HONS, the hash-consing constructor from ACL2(h). Logically, HONS 
is nothing more than CONS. But in the execution, HONS(a,ft) checks whether there is already a hons 
pair corresponding to (a . b) and, if so, returns the existing pair instead of making a new one. The 
bookkeeping that keeps track of honses is done in ACL2(h) via Common Lisp hash tables. These tables 
are extended when we build new Hons-AIGs, and, in some sense, contain the DAG for all Hons-AIGs. 

We usually build Hons-AIGs with constructors named AigAnd, AigOr, etc., that apply basic sim- 
plifications like constant folding and reduce expressions like a l\a and a A -<a. Identifying expressions 
like a A a would be very expensive if we were to use a deep structural-equality check, but ACL2(h) has 
a HONS-EQUAL function that boils down to pointer-equality for honses. Correctness theorems for these 
constructors are trivial and are stated in terms of AigEval, e.g., for AigAnd we prove 

AlGEVAL(AlGAND(a,ft),em>) = AlGEVAh(a,env) AAlGEVAh(b,env). 



2.2 AIG Traversal and Memoization 

Almost any algorithm that operates on Hons-AIGs needs a way to avoid repeatedly 
visiting the same node. For instance, to the right is an AIG that represents a = b. 
Notice in particular how a and b are reused as fanins — inputs to AND gates — 
shared by both ab and ab. Because of this sharing, if we evaluate this AIG with 
AigEval as above, we will end up evaluating a twice: once because it is a fanin 
of ab, and once because it is a fanin of ab. We will evaluate b twice for the same 
reason. As we generate larger AIGs with lots of shared structure, the cost of this 
recomputation grows exponentially. 

The ACL2(h) system has a function memoization capability that we can use 
to avoid this recomputation. This mechanism is especially convenient: we simply 
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say, "memoize AigEval," and we are done. The logical definition of AigEval is unchanged, but its 
executable definition is extended with a Common Lisp hash table that records its return values: when 
AigEval reaches a node whose value has already been computed, this cached return value is returned, 
making the computation linear in time and space in the number of unique AIG nodes. 

Automatic memoization works well for AigEval, but is not suitable for some other AIG algorithms. 
Notice that as AigEval recurs, its env argument remains fixed. In many other algorithms, there are 
additional parameters that change as we recur over the AIG. These changes ruin simple memoization, 
because, e.g., when we encounter a for the second time, these arguments may now be different. In these 
cases, we generally represent the memo table explicitly as a "fast" association list. This is roughly as 
efficient as automatic memoization; fast alists provide hash-table speeds for honsed keys. Unfortunately, 
it is far less convenient. When we verify these kind of algorithms, we typically need invariants that say 
the memo tables have correct entries. 



2.3 Reasoning about Hons-AIGs 

Hons-AIGs are a non-canonical representation, meaning that there are different ways to represent the 
same Boolean function. For instance, we could represent the function a Ab as (a . b),oras(b . a), 
or (a . (b . t ) ) , and so on. Because of this, when we reason about algorithms that manipulate AIGs, 
we typically do not want to deal with structural equality, but rather semantic equivalence, 

AlGEQUIv(a,Z?) =Venv : AlGEVAL(a,e?iv) = AlGEVAL(£,em>). 

This equivalence relation has a strong analogue in set theory. Instead of thinking about an AIG as 
some particular cons tree, think about it as a set whose elements are the environments that satisfy it. 
That is, for the AIG a, think of the set {env : AlGEVAL(a,em>) = t}. Seen this way, AlGEQUlv(a,&) is 
nothing more than set equality; AigAnd is set intersection, AigOr is union, etc. 

To reason about AigEquiv in ACL2, we use the w/toe.w[j] clause processor, which is much like 
Greve's quant system [19] for automatically Skolemizing and instantiating quantified formulas. When 
ACL2 tries to prove a conclusion of the form AlGEQUlv(a,ft), this clause processor reduces the prob- 
lem to showing that a and b have the same evaluation under a particular env, similar to the pick-a- 
point strategy used in Davis' osets library lfl3l . Going further, when we have a hypothesis of the form 
AlGEQUlv(a,£>), the clause processor will add a witnessing environments env for which a and b are 
known to produce the same evaluation. 

We have implemented and verified several algorithms on Hons-AIGs. As basic building blocks, we 
have routines for collecting the variables in an AIG and composing AIGs with other AIGs. We have also 
developed routines for random vector simulation; this is like AigEval, except that we do n simulations 
at a time using n-bit integers by replacing Boolean AND and NOT with bitwise AND and NOT. We also 
developed a basic way to partition AIGs into equivalence classes by first using random vector simulation 
as a coarse filter, then use SAT to differentiate the AIGs that were the same across random simulations. 
The most sophisticated algorithm that has been verified atop Hons-AIGs is the AIG to BDD conversion 
algorithm of Swords and Hunt [29]. This algorithm avoids converting irrelevant parts of the AIG, which 
is important since constructing BDDs is often prohibitively expensive. 



See clause-processors/witness-cp in the ACL2 Books. 
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2.4 Critique of Hons-AIGs 

Hons-AIGs have a lot of redeeming qualities. By hiding the details of their DAG representation beneath 
ACL2(h)'s implementation of hash consing, we can think of AIG "nodes" as if they are ordinary ACL2 
objects. An important consequence is that we can embed Hons-AIGs within other ACL2 objects, e.g., we 
often deal with lists or alists of Hons-AIGs. Hiding the graph from the logic means we don't need to prove 
any invariant-preservation theorems, and even the memoization needed to avoid repeating computations 
can often be hidden from the logic, thanks to ACL2(h)'s memoize command. 

Unfortunately, Hons-AIGs are not especially efficient. Conventional AIG representations use topo- 
logically ordered arrays of nodes. By comparison, the nodes of Hons-AIGs, being conses, have worse 
memory locality and must be traversed during garbage collection, reducing overall performance. 

Algorithms that operate over Hons-AIGs have to do a lot of hashing. Even for something as simple 
as AigEval, for instance, we look up each AND node in a memoization table. This means hashing on 
the address of a cons regardless of whether we use ACL2(h) memoization or fast-alists for the table. In 
contrast, in an array-based representation, each node has a successive index and so, e.g., AigEval could 
simply allocate an array and use array-indexing, instead of hashing, to do the memoization. In packages 
like ABC, some node representations include scratch space that can be used for such purposes, giving 
even better memory locality. Our memoization schemes also require allocation, hash-table growth, etc., 
and ultimately impact garbage collection performance. 

Hons-AIGs also have one node for every AND and NOT operation, whereas most AIG representations 
avoid NOT nodes by encoding negation information in the fanins of AND nodes. For rough perspective, 
we measured the Hons-AIG for a GL proof that shows our media unit correctly implements the x86 
PSADBW instruction. We found 53.3% AND nodes and 46.7% NOT nodes. In short, the Hons-AIG 
representation uses about twice as many nodes as a typical representation uses. This is unfortunate for 
memory locality and makes AIG construction more expensive since we have to hash to create NOT nodes. 

3 Aignet Library 

In contrast to the Hons-AIG library, our Aignet library is designed for better execution efficiency at the 
expense of logical simplicity. Its implementation is similar to those in high-performance AIG packages 
such as ABC |Q. 

3.1 Representation 

In Aignet, an AIG is represented in a single-threaded object (stobj) [6|. The Aignet stobj may be thought 
of as a medium for storing a network of inter-related (combinational) Boolean formulas. Unlike Hons- 
AIGs, it also directly supports viewing these formulas as a (sequential) finite state machine. 

The primary content of the Aignet stobj is an array of nodes. Each node has an ID which is its index 
in the array. We usually refer to stored formulas via a literal, which is a combination of an ID with a bit 
saying whether it is negated or not. A literal is represented as a natural number using the construction 

MkLit (id, neg) = 2 id + neg. 

Extracting the parts of a literal can be implemented efficiently; in C-like notation, 

LlTlD(lit) =lit»\ 
LitNeg (//?) = //?&!. 
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Every Aignet has a constant-false node with ID 0. Hence, the literal means constant-false, and the 
literal 1 means constant-true. 

Here is an example circuit and its node array representation: 



^> 



2 



5 3 



^3 



ID 


Node Type 


Fanins 


Other 





Constant False 






1 


Primary Input 






2 


Primary Input 






3 


Register Output 






4 


AND gate 


5,6 




5 


Register Input 


9 


RO:3 


6 


AND gate 


1,2 




7 


AND gate 


8, 12 




8 


Primary Output 


14 





Each node in the array has a type. This circuit contains nodes of all six types: constant false, primary 
input (PI), primary output (PO), AND gate, register input (RI), and register output (RO). Unlike Hons- 
AIGs, there are no NOT gates in the node array. Instead, the fanins of each node are encoded as literals, 
which may or may not be negated. Negations are shown as bubbles in the picture. For instance: the fanin 
of node 5 is the negation of node 4, so its fanin literal is 2 • 4 + 1 = 9; the fanin of node 8 is node 7, 
without negation, so its fanin literal is 14. 

Register input and output nodes allow an Aignet to represent a sequential circuit or finite state ma- 
chine. However, in many algorithms, the circuit is viewed as purely combinational. In these cases, 
register outputs are treated similarly to primary inputs, both being essentially free variables; register in- 
puts are treated like to primary outputs, both being essentially a way to label certain formulas. Thus, we 
sometimes refer to primary inputs and register outputs collectively as combinational inputs (CIs), and 
primary outputs and register inputs collectively as combinational outputs (COs). 

Primary inputs are easy to understand: they are like the variables in a Hons-AIG. But what are pri- 
mary outputs? Any AIG simplification tends to affect the numbering of nodes: nodes may be reordered, 
eliminated, etc. But by convention, we preserve the ordering among primary outputs. The sole purpose 
of primary outputs is to maintain an order, so that before and after a transformation, the nth primary 
output always refers to the same formula. For similar reasons, we also generally expect that the order of 
primary inputs and (for combinational simplification, at least) register outputs will remain the same. 

The Aignet stobj supports this convention by maintaining arrays that allow us to look up the ID of, 
e.g., the nth primary input, and also to do reverse lookups. These extra mappings are not material to the 
logical meaning of the stobj, which is completely expressed by the node table; e.g., looking up the rath 
input in the input array is always the same as scanning the node table for the rath PI node. 



3.2 Semantics 



Since the Aignet stobj can be viewed as both a medium for storing (combinational) Boolean formulas 
and (sequential) finite state machines, we have both combinational and sequential evaluation semantics; 
we describe combinational evaluation first, since sequential evaluation builds on it. 



EvalID (id, V in ,V reg ) 



A 
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3.2.1 Combinational Semantics 

An Aignet node or literal is evaluated under an assignment of bits to the combinational inputs. This 
assignment is given by a pair of arrays Vi n ,V reg , where, e.g., Vm[n] is the value to use for the rath primary 
input, and V reg [n] is the value for the rath register output. Evaluation is defined as follows, except that we 
hide the stobj argument for simpler presentation: 

EvalLit (lit, V in ,V reg ) = EvalID(Lit\d (lit), V in ,V reg ) xor LlTNEG(7/f) 

(0 if Type(W) = Const 

V in [lNlDx(id)] if TYPE(id) = PI 

V reg [REGlDx(id)] if Type(k/) = RO 
EvalLit (Fanin 1 (id) , V in ,V reg ) 

& EvALLiT(FANiN2(/<i),^„,V r ^) if Type(j'J) = And 

{EvalLit (Fanin (id), V in ,V reg ) if Type(j^) e {PO,RI} 



This evaluation function is nice for reasoning but not practical for execution since it does no mem- 
oization. A more practical evaluation function simply does a linear sweep over the node array, storing 
each node's value in a result array. We require the node array to be topologically ordered, so that each 
fanin's value is already computed. This makes evaluation linear in the size of the graph. (Topological 
ordering is also important to show that EvalLit terminates!) 

Evaluation is a good example of the performance 
advantage of the Aignet representation over the Hons- 
AIG representation. We benchmarked evaluating the 
functions for a hardware module with 3,664 input vari- 
ables, 131,605 AND nodes, and (in the Hons-AIG repre- 
sentation) 121,490 NOT nodes. We also include a com- 
parison with ABC, compiled with and without GCC's 
"-O" optimization flag. In each case, we evaluated the 
network under the all-false environment 1000 times. For the Hons-AIG test, we cleared the AigEval 
memoization hash table at each iteration, and used a large enough Lisp heap to avoid garbage collection, 
so that GC time was not counted. For the Aignet and ABC tests, we used a bit array to remember node 
values, re-allocating and clearing this array at each iteration. 



3.2.2 Sequential Semantics 

Sequential evaluation depends on an initial assignment to the registers and a series of assignments to the 
primary inputs. A common convention is to assume that each register's initial value is 0, but the Aignet 
library does not enforce this convention. Letting V, m - be the initial state values (indexed by register 
number) and Vfr be a two-dimensional array giving the input assignments at each frame (indexed first by 



Representation 


Time 


Allocation 


Hons-AIG 


57.6 sec 


2.62 GB 


Aignet 


6.85 sec 


16.2 MB 


ABC (no opt.) 


4.03 sec 


16.0 MB 


ABC (opt.) 


1.21 sec 


16.0 MB 
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frame, then by input number), the evaluation of a node or literal at frame k is given by: 
SEQEvLlT(£,//?,ty r ,Vi m -) - SEQEvID(£,LlTlD(7zY),ty r ,V; m ) xor LitNeg(ZiY) 



SEQEvID(k,id,Vfr,V ini ) 



(0 

V fr [k}[lNlDX(id)] 
V, m [REGlDX(/fi?)] 

SEQEvID(A:-l,REGlN(/(i),V^,V im ) 
SeqEvLit(&, Fanin 1 (id) , V fr , V ini ) 
&SEQEvLiT(k,FAmN2(id),V fr ,Vi ni ) 

k SEQEvLlT(A;,FANIN(jrf),V^,V;„/) 



if TYPE(irf) = Const 

ifTYPE(/<f)=PI 

if TYPE(jJ) = RO and k = 

if Type (z'<i) = RO and k > 

if Type(W) = And 
ifTYPE(W) e{PO,RI}. 



Alternatively, we can define SeqEvID in terms of the combinational semantics EvalId as follows: 



SEQEvlD(k,id,V fr ,V ini ) = EVALlD («/,%[£],REGFRAME (k,V fr ,V ini )) 

REGFRAME(k,Vf r ,V M ){n] = < / 

v J ni lSEQEVlD(ifc-l,REGlN(NTHREG(n)),^,V^) ifjt>0. 



if/< = 



Here, we capture the values on the register outputs at each frame k as a bit array, RegFrame(/c, V/ r , Vm). 
This takes the initial values at frame 0, and for later frames collects the register input values computed 
for the previous frame. Then the sequential evaluation of any node in frame k reduces to a combinational 
evaluation of the inputs and register values for that frame. 

Either definition is well suited for reasoning but performs poorly on real examples since it does no 
memoization. An efficient implementation that linearly computes each frame in sequence by storing the 
current values in a bit array can be proven to compute these values. 



3.3 Constructing Aignets 

The following basic functions are used to add nodes to an Aignet stobj. The stobj is both an input and 
output of all functions below, but is omitted for brevity: 

• AddInput() — >• lit: Adds a new primary input node and returns its non-negated literal. 

• AddRegQ —> lit: Adds a new register output node and returns its non-negated literal. 

• Add And (lit 1 ,lit2) — > lit: Adds a new AND gate of litl,lit2; returns its non-negated literal. 

• AddOutput(/2'?): Adds a new primary output with fanin lit. 

• AddRegIn(//?, ro): Adds a new register input node with fanin lit and register output ID ro. 

Add And is a very low-level way to add a gate to an Aignet stobj. It unconditionally adds an AND 
node with no simplification and with no regard to whether such a node already exists. Higher-level 
functions called HashAnd, HashOr, HashXor, and HashMux can add logic in a smarter way: 

• They may optionally propagate constants, eliminate certain tautologies and contradictions, detect 
cases where an AND is logically equivalent to one of its fanins, etc., to produce equivalent formulas 
with fewer nodes. These reductions are described in Brummayer and Biere O. 
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• They allow structural hashing (strashing): when preparing to add an AND node, we check to see 
if there is an existing AND node with the same fanins, and if so reuse it. Our structural hashing 
implementation currently requires a trust tag to allow stobjs to have hash table fields; we believe it 
is sound, and perhaps it can be integrated into ACL2 in the future. 

In Hons-AIGs, structural hashing is automatic due to our use of HONS, but in our stobj-based ap- 
proach the strash table is necessarily visible in the logic. Normally we would need an invariant about 
the strash table to know that our construction functions return nodes with the right meanings; this would 
mean proving invariant-preservation theorems for many algorithms. We initially tried to do this, but 
found it to be tedious. We then realized that it is reasonably fas^j to check whether a hit in the strash 
table actually gives the correct node. Adding this runtime check to our strash lookup obviates the need 
for an invariant altogether! Explicit hashing also has some advantages: once we are done building a 
network we may throw out the strash table and reclaim its memory while keeping the AIG itself. 

Each of these functions returns a literal that provably evaluates to the correct function of the evalu- 
ations of the input literals, and also provably preserves the meaning of previously existing literals. For 
example, in the case of HashAnd, letting 

(newlit, strash', aignet') = HashAnd(//£ i , lit%, strash, simp_opts, aignet) , 

the new-literal correctness theorem is 

EvalLit (newlit, Vi»,V reg , aignet 1 ) = EvalLit (lit i,Vi n ,V reg , aignet) A 

E VALLlT (IU2 , Vi n , V reg , aignet) , 

and the previous-literal preservation theorem is 

LlTlD (oldlit) <N\]MNODES(aignet) =4> EnalEyt (oldlit, V in ,V reg , aignet') = 

EvalLit (oldlit, Vi„ , V reg , aignet) . 

This preservation property is an instance of a more pervasive pattern: most functions which modify 
an Aignet stobj are simply adding new nodes, without modifying the existing ones. This means that 
many properties of existing nodes in the original network remain true in the modified network. To take 
advantage of this, we use a relation 

AlGNETEXTENSION(«e>V,oW) = 

NUMNODES(oW) < NUMNODES(rcew) A 

V id < NumNodes (old) : NODES (new) [i d] = NODES (old) [id] , 

that is, all nodes that were in the old network are still the same in the new network. 

Most functions that modify an Aignet stobj produce an output Aignet which is an extension of the 
input Aignet, and there are many useful preservation properties that follow when we know this is the 
case. For example, when we know AignetExtension(ti£w,oW), it follows that: 

• an ID that is within bounds for old is still in-bounds for new 

• a list of in-bounds literals for old is still in-bounds for new 



This runtime check costs an overhead of 30-40% in the worst case, i.e., when every strash lookup is a hit and no sim- 
plification is performed. We generally expect to see fewer strash hits and to perform simplification, which has much greater 
overhead. And, at any rate, Aignet construction is typically not a bottleneck. 
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• evaluation of an in-bounds literal in old is the same as its evaluation in new 

• the Mb. output in old still has the same ID in new. 

Written as rewrite rules, these preservation properties generally bind new in the LHS, but have old 
as a free variable. We use a bind-free [20] form to instruct ACL2 how to bind old. In particular, if 
new is bound to a stobj return value of a function call, we will try binding old to the corresponding stobj 
input of that function call. Otherwise, we fall back to searching the type-alist for a known-true term of 
the form AlGNETEXTENSlON(«ew, old). This strategy works well in most cases, but in some cases it 
would be better to try multiple different bindings for old, in case the first one fails to satisfy one of the 
other hypotheses. This capability is not yet available to bind-free. 

In the Aignet library sources, we have identified about 40 such preservation properties. Furthermore, 
we have proven that about 25 Aignet-modifying functions return an Aignet that is an extension of their 
input. If we tried to do without the AignetExtension property and instead prove each of the 40 
preservation properties for all 25 functions then we would need 1000 rules, whereas we now accomplish 
the same thing with only 65 rules. 

3.4 CNF Generation 

We have implemented and proven correct a CNF generation algorithm for Aignet stobjs. Today, this 
algorithm allows us to export AIG-derived problems to an external SAT solver. For the future, it is also 
groundwork toward implementing and verifying many AIG algorithms that are based on incremental 
SAT lfT6l . a technique for efficiently checking multiple related satisfiability queries. For instance, modern 
model- and equivalence-checking packages make use of: 

• Fraiging or SAT sweeping ll26l is a combinational simplification algorithm designed to eliminate 
circuit nodes that are redundant; that is, any nodes whose functionality is provably the same as an- 
other. It finds candidate combinational equivalences among circuit nodes using random simulation, 
then attempts to prove or disprove each equivalence using SAT. 

• Signal correlation ll24l is a sequential simplification algorithm that somewhat resembles fraiging, 
but allows elimination of nodes that are sequentially equivalent, even if they are not combination- 
ally equivalent. It finds candidate sequential equivalences using random simulation, then uses SAT 
to attempt to prove all equivalences by induction over one or more frames. 

• IC3 or property directed reachability J7J H31 is an algorithm for checking safety properties. It 
operates by repeatedly using SAT to refine an overapproximation of the reachable state space until 
it is shown that no bad states are reachable or a counterexample is found. 

An incremental SAT solver maintains a database of clauses, of which some are given and some are 
learned. Typically the CNF database as a whole — the conjunction of all the clauses — is known to be 
satisfiable. The problems to solve are given by providing a cube (a conjunction of literals) as an additional 
constraint. The solver checks the satisfiability of the cube together with the clause database, but only 
learns clauses relative to the database, not assuming the cube. The point is: subsequent SAT checks may 
reuse heuristic information and learned clauses even though the constraints change. 

An incremental SAT interface is useful for solving problems generated by AIG-based algorithms. 
The idea here is to generate the clause database from the circuit by adding structural constraints as in 
the Tseitin [30] transform. For instance, if c is an AND node with fanins a and b, we add the clauses for 
->a ^> -ic, -<b => -ic, and (af\b) =4> c. These clauses fully and exactly represent the logical meaning of 



Jared Davis and Sol Swords 105 

the AND node: any possible configuration of the AND gate and its fanins satisfies the clauses, and any 
satisfying assignment of the clauses is a possible configuration of the AND gate. 

When we generate a clause database in this way, any evaluation of the AIG induces a satisfying 
assignment of the database by assigning each literal its value under the evaluation. This allows us to 
prove facts about the network by checking satisfiability of the database together with some additional 
constraints as follows. Suppose we generate a clause database from part of a circuit. Suppose we prove 
that the database together with a certain constraint — say, some literal — is unsatisfiable. This proves that 
this literal may not be true under any evaluation of the circuit. Why? Suppose we have an assignment to 
the combinational inputs of the network that makes this literal true. This produces a satisfying assignment 
of the database, and the literal is true, so the constraint is satisfied, which we have proved impossible. 
This generalizes to any additional constraint not in the database, most commonly a cube of literals. 

Conversely, if the database contains sufficient structural constraints relating some set of nodes to 
their fanins, and also transitively for their fanins reaching back to the combinational inputs, then any 
satisfying assignment of the database induces an assignment to the CIs of the circuit under which each 
node in the set evaluates to its ID's value under the satisfying assignment. This allows us to transform 
a satisfying assignment produced by a SAT solver into an assignment to the combinational inputs that 
satisfies whatever constraint we added to the clause database. 

Our CNF generation algorithm is a commonly-implemented [15] variation on the standard Tseitin 
transform. This variation has two optimizations that reduce the number of variables and clauses that will 
be given to the solver, which tends to speed up SAT checks. First, it recognizes supergates: trees of 
multiple AND gates, without negations, where only the root has multiple fanouts. For each supergate it 
generates n binary clauses and one clause of length n + 1 : 

-ij'o => ~>o 

o = io A i\ A . . . A i n — > 

-ii n =4> -io 

/o A . . . A i n =4> o 

Second, it recognizes two-level nestings of gates representing a mux (if-then-else) structure, and gener- 
ates a special set of clauses: 



o = if a then b else c 



The last two clauses are unnecessary but are included to improve SAT performance ifTSI ; they are omitted 
in the degenerate case where b = ->c, i.e. an XOR gate. 

The CNF generation function has the following signature: 

AddCnf (id, marks, cnf , aignet) — > (marks' ,cnf'). 

Here, cnf is the accumulator for clauses, and marks is a bit array that tracks the identifiers whose struc- 
tural constraints (recursively, back to the CIs) are encoded in the CNF. 

We prove that AddCnf marks id and preserves an invariant, CnfForAignet(cti/', marks, aignet). 
When this invariant holds, we can map evaluations of aignet to satisfying assignments of cnf and vice 
versa, as described above. To state the invariant we need some additional definitions: 



af\b 


=> 





-iflAc 


^ 





aA-ife 


=^ 


-1(9 


-iaA-iC 


=^ 


-io 


bAc 


=> 





-ifcA-ic 


^ 


-10 
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• CNFEVAL(cn/,ewv) evaluates a CNF formula under a bit array env mapping IDs to values. 

• AlGNEJEVAh(aignet,env) updates env so that the values assigned to CI IDs are preserved, but for 
all other IDs, the values under those CI assignments are stored. 

• MARKED~VALSCORRECT(aignet, marks, env) is true when env binds every marked ID to its eval- 
uation under the CI assignments, i.e., when 

\/id : marks[id] =4> AlGNETEv Ah(aignet,env)[id] = env[id]. 
We can now define our invariant: 

CnfForAignet(c«/', marks, aignet) = 

Venv : (CnfEval (en/, env) =^ Marked VaesCorrect (aignet, marks, env)) 

ACNFEVAh(cnf,AlGNETEVAL(aignet,env)). 

The two conjuncts are the two directions. The first says, for any satisfying assignment of the CNF, how 
to obtain a consistent evaluation of the circuit. The second says, given an evaluation of the circuit, how 
to obtain a satisfying assignment of the CNF. 

When cnf is empty and no nodes are marked, CnfForAignet is trivially true. This is the starting 
point for adding nodes to cnf. Then, we prove our invariant is preserved by AddCnf, i.e., 

let (marks' , cnf') = AddCnf (id, marks, cnf , aignet) in 

CNFFORAlGNET(cra/', marks, aignet) =>• CnfF OR AlGNET (cnf , marks' , aignet) . 

When we know that CnfForAignet holds, then we know that satisfiability proofs about the CNF 
(with additional constraints) imply satisfiability results about the circuit. For example, we define a func- 
tion AlGNETClsToCNFENV^,^, aignet) and prove 

CNFFORAlGNET(crc/', marks, aignet) 
A LlTEVAL(lit,Vin,V reg , aignet) 
A marks[LnlD(lit)] 

CnfEval (cnf I) {lit} , AlGNETClsToCNFENV (V in , V reg , aignet)) . 

Therefore if cnf Li {lit} is unsatisfiable, then there is no Vi n ,V reg for which LnEYAh(lit,Vi n ,V reg , aignet). 
Conversely, we have CNFENVToAlGNETCls(e«v,a/g«e?) for which we prove: 

CNFF OR AlGNET (cnf , marks, aignet) 
A CnfEval (cnf U {lit} , env) 
A marks[LlTlD(lit)] 
=^ 

let (V in ,V reg ) = CNFENVToAlGNETOs(em>, aignet) in 
LitEval(Zj'?, Vi n , V reg , aignet) . 

That is, a satisfying assignment for cnf Li {lit} can be converted to a CI assignment under which lit is 
satisfied. 
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4 GL Integration 



In previous work E8I we introduced GL, a framework for automatically proving "finite" ACL2 theorems. 
GL works by symbolically executing ACL2 formulas to bit-blast (translate) them into Boolean formulas, 
which can then be solved using a tool like a BDD package or a SAT solver. 

We use GL to verify x86 execution units ETl . Its ability to solve these problems depends on the 
performance of its symbolic execution and the capacity of these solvers. Without help, GL can verify 
many instructions within a few seconds, and some others in a few minutes. For harder instructions, we 
have to manually intervene, e.g., we might decompose the proof in some way. 

We want to scale up GL to avoid this human effort. Toward this end, we have developed a new 
GL mode that uses Aignet and its CNF conversion algorithm to connect GL to any off-the-shelf SAT 
solver that implements the DIMACS format. As we will explain shortly, this already has advantages 
over GLs previous approach to using SAT, and it opens up a promising route for future improvements, 
viz. simplifying the AIG before calling SAT. 

GL can operate in different modes that govern how Boolean formulas will be represented during the 
symbolic execution, and how these formulas will be solved. The mode to use can be chosen at run- 
time on a per-proof basis using attachments [22], and this choice can have a significant impact on GLs 
performance. Previously, GL has supported three modes: BDD mode, AIG mode, and AIG-Cert mode. 
We describe these and our new Satlink mode modes below. But first, here is a sketch: 



BDD Mode 



\r 




examples 



"symbolic execution 
is correct" 



AIG and AIG-Cert Modes 




"symbolic execution 
is correct" 



/ AIG Mode 



Satlink Mode 




"symbolic execution 
is correct" 



"aignet construction 
is correct" 



'cnf conversion 
is correct" 



(eventually: or verify) 
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In BDD mode (the default), GL uses a simple Hons-based BDD representation @ of Boolean func- 
tions during symbolic execution, and no back-end solver is needed because the truth of a BDD is imme- 
diately evident. This works well when the user knows how to choose a good BDD ordering, but is not 
well-suited for larger, less-structured problems. 

In AIG and AIG-Cert modes, Hons-AIGs are used as the Boolean function representation during 
symbolic execution, and a SAT solver is used as the back-end. These modes are convenient since a good 
BDD ordering is not needed, and they tend to outperform BDDs on less-structured problems. In AIG 
mode, the SAT solver's claims of UNSAT are trusted without verification; in AIG-Cert mode they are 
checked using a verified checker developed by Matt Kaufmann. Both AIG modes are integrated with a 
SAT solver that can directly accept AIGs as inputs, but which unfortunately we cannot release. 

Our new mode, Satlink mode, still uses Hons-AIGs as the Boolean function representation during 
symbolic execution. We then convert the goal Hons-AIG into an Aignet and use our verified CNF 
conversion algorithm to generate clauses that can be sent to any SAT solver that implements the usual 
DIMACS format. Like AIG mode, the SAT solver is simply trusted to be correct. We have not yet 
implemented a proof-checking scheme for this Satlink approach, but we are optimistic that recent work 
by Wetzler, et al. [32] might lead to a high-quality way to fill in this gap. 

Already, Satlink mode appears to be quite 

promising. For instance, we applied it to a some- 128-bit PSADBW Parameterized Full 



what difficult proof: the correctness of our me- AIG Mode 84 38 sec ? (>24 hr) 

dia unit's 128-bit x86 PSADBW instruction. We Satlink/Lingeling 62.02 sec 50.08 sec 

have never successfully proved this theorem with Satlink/Glucose 6.11 sec 14.88 sec 
BDDs. Even for AIG mode, performance was so 



bad that we spent time manually parameterizing [28] the theorem. State-of-the-art tools like Glucose 
and Lingeling [3 ] can solve the full problem quickly, making this work unnecessary ! 

A promising direction for future work is to simplify the Aignet before converting it to CNF. To 
explore this, we developed an unverified, experimental way to use ABC's rewriting and fraiging routines 
to do some light-weight simplification of the AIG that arises from symbolic simulation; the simplified 
problem is then solved with ABC's built-in SAT solver or by giving it to a back-end tool. It appears that 
these AIG algorithms may allow GL to scale far beyond its current capability. 

To illustrate, we consider a proof of correctness for a 

hardware module that computes four independent single- Independent FADDs Total Time 

precision floating point additions in parallel. The correctness 

;, • tt . • i n rt, *u v ■ * AIG Mode ? (>24 hr) 

theorem is stated as a single GL theorem, not broken into any 

„,. , , . , , ., £ . . Sathnk/Lingelmg 18,581 sec 

cases. This problem is beyond the capacity of our existing ° ° 

tit^t^ at/- j , irt , t AT1/ ^ , c .,. , „-,, Satlink/Glucose 572 sec 

BDD or AIG modes. Without ABC, only Satlink/Glucose 

, ,, _.. " „,, ABC/integrated 1,446 sec 

can solve it in a reasonable amount of time. When we use ° 

.„_, . j. ,. ,. . ,. „ . , .. ABC/Satlink/Lingeling 442 sec 

ABC to perform some light-weight framing and rewriting ° ° 

„ „ _,, F , * u , , f« * * a ABC/Satlink/Glucose 121 sec 

first, Glucose can solve the problem almost 5x taster, and 

the problem also becomes tractable for other solvers. 

5 Conclusions 

Hons-AIGs and Aignet are two alternatives for representing AIGs that have complementary strengths 
and weaknesses. By keeping the DAG representation implicit, Hons-AIGs provide an especially simple 
logical story: we can deal in self-contained Boolean functions rather than a monolithic graph, and we 
can reason about AIG operations at the semantic level. In contrast, by making the DAG representation 
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explicit, Aignet allows us to write more efficient algorithms. Reasoning about these algorithms is more 
difficult and involves the kinds of invariants associated with any imperative code, but relationships like 
AignetExtension go a long way toward making this tractable and we have been able to implement 
and verify useful Aignet algorithms, e.g., CNF conversion. 

Our work to integrate Aignet into GL allows ACL2 users to make use of state-of-the-art SAT solvers 
to handle finite ACL2 goals. At present these SAT solvers are simply trusted. In the future, a verified 
SAT proof checker might be integrated into the flow to ensure correct reasoning. 

This work is a starting point toward verified implementations of AIG simplification algorithms like 
fraiging and rewriting. We have seen that (unverified) implementations of these algorithms can signifi- 
cantly reduce the difficulty of problems that GL gives to the SAT solver, so this is a promising direction 
for increasing the scale of theorems that GL can automatically prove. 

The source code for our AIG representations, algorithms, and GL connection are included in the 



ACL2 Community Books for ACL2 6.1; see http : //acl2-books . googlecode . com/ Except for the 



Aignet library we rely on features specific to ACL2(h), so please see books/centaur/README . html for 
important setup information. Our Hons-AIG representation and algorithms are found in centaur/aig 
and the Aignet library is in centaur /aignet. The Centaur Hardware Verification Tutorial, available in 
centaur/tutorial, shows how to use the new Satlink mode; see especially sat . lsp. 

We thank Bob Boyer, Warren Hunt, and Matt Kaufmann for contributing to the development of 
ACL2(h). We thank Matt Kaufmann for improvements to ACL2 in support of this work, especially re- 
lated to abstract stobjs and non-executability. We thank Matt Kaufmann, David Rager, Anna Slobadova, 
and Nathan Wetzler for their corrections and helpful feedback on drafts of this paper. 
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